(レポート) Elastic{ON} 2016: All the Data That’s Fit to Find: Search #elasticon

はじめに

本記事はElastic{ON} 2016のセッション、「All the Data That's Fit to Find: Search @ The New York Times」のレポートです。

スピーカーはNew York TimesのBoerge Svingen。

レポート

・テキストサーチで3つ考えるべきことがある ・Keep It Simple。 ・なぜGoogleを使わないのか？ ・Elasticsearchはテキストサーチにおけるright toolか？

・Background。20年前は紙のみ、今はwebへ。 ・New York Timesの最初の検索エンジンは1969年にLaunch。 ・以降、様々な検索の仕組みを使ってきた。

・Explicit search。エンドユーザーが直接検索。nytimes.comやネイティブアプリ、検索API、timesmachineサイト、e.t.c... ・Implicit search。softwareからの検索。最新記事一覧など。

・Ingestion。検索元は様々。CMS、レガシーシステム、ファイル。レイテンシは1sec以下、レイテンシが低いことが重要。

・検索のユースケース。記事検索、あなた自身が書いたものの検索、レビュー、レシピ、カジュアルにニュースを検索できること。 ・なぜGoogleを使わないのか？Webサイトを自分でコントロールしたい、ネイティブアプリでは使えない、自分たちのほうが自分たちのコンテンツのベターを知っている。

・セットアップ。全てAWS。デプロイは自前のツール。NagiosとNew Relicでモニタリング。SumoLogicでログ管理と解析。

・システムセットアップ。2つの本番環境クラスタ。 DNSベースでフェイルオーバーさせている。本番用ESクラスタは16node(m1.xlarge)

・構成図。SQS、S3、MongoDB & Elasticsearchを活用。Elastic BeanstalkでHandler、Normalization、Merge、Indexerを構成。

・私たちのこれから。 ・シンプルに。全てのドキュメントをElasticsearchへ。MongoDBの廃止。Demand driven API化。

・Replay。全てのコンテンツをKafkaへ。

・Keep all cluster is busy。可視化。Vagrantを利用。フルパイプラインの構成が簡単。

・将来構成図。CMSからKafkaへ、Logstash経由でElasticsearch。

・Googleより良いところを見つけ出す。ユーザーを知る。違いを知る。 ・Infrastructure is hard。デプロイ、アップグレード、reindex、検索クラスタの作成。それらを簡単に。 ・具体的に考えるべきこと。インフラのバージョン管理。Vagrantによる構成。サーバをImmutableに。新しいstackの作成を簡単に、かつ自動的に。

・Elasticsearchはテキスト検索にしか使えない？いや、2.0で新しい機能がたくさん追加。SearchだけじゃなくAnalyticsの機能が大幅に増えている。

まとめ

長い歴史のある新聞社なだけに、いろいろな試行錯誤があるのと、現在はフルAWSでクラウドネイティブに構成されていることが分かって、面白いセッションでした。それにしても、今回はどこに行ってもKafkaの話題があがりますね。これから大きく注目されていくのではないでしょうか。